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Remarks 

1) Claims 1,3,8-15, and 17-25 are pending in he application, and stand finally 
rejected. Limitations of cancelled claims have been incorporated in the respective 
independent claims- 

2) The present invention is directed to a cluster server, as was defined in paragraphs 
[02] and elsewhere, where a packet is sent from a client to a first server, and if for 
any reason this server is not the server to handle the packet, the server utilizes a 
redirection database to provide an address of a server capable of performing the 
service. The fiist server returns the SAME PACKET (i.e. a series of bits that 
contain the same transmitted payload), together with a redirection header. The 
redirection header contains at least one flag o indicate to the client that the 
redirection should be made once, permanently, or for a limited time. The client is 
constructed to distinguish such header and to act thereupon. Those distinctions^ 
including the difference between them and the cited art, were clearly made, not 
only in the original application as filed* but also in the response to the first office 
action, 

3) Applicant protests the Office complete failure to substantially relate to the 
argumentsraisedintheamendmentfiledFeb. 28, 2005. Applicant directs the 
Office's attention to MPEP 2143.03 which requires all claim limitations to taught 
or suggested. The Office failed to specifically show ANY HINT OR TEACHING 
in the references, separately or in combination, which disclose that the SAME 
PACKET AND A REROUTING HEADER ARB TRANSMITTED BACK TO 
THE SOURCE ADDRESS, (i.e, the Office failed to show all claim limitadons, 
see In re Royka, 490 F.2d 981) The Office did not relate to this point m any 
substantive manner. Furthermore, in relation to the argument that McCanne 
DOES NOT TEACH A SERVER CLUSTER as clearly and specifically defined 
in the present ^plicatioii, the Office provided merely an unsubstantiated response 
that the 'the position of the Examiner is that McCanne teaches a method of 

/plication No.: 09j^7,725 — 7 of 12 DocketflUlUS-FIRSTHOP 



PAGE 8/13 • RCVD AT 8/17/2005 10:46:06 AM [Eastern Daylight Time] ' SVR:USPTO-EFXRF-6/29 • DNIS:2738300 - CSIO:-i-1 (207) 767-5324 ' DURATION (mm-ss):07-46 



17/08/2005 10:51 FROM: +1 (207) 767-5324 Saltamar Innovations TO: 15712738300 PAGE: 009 OF 013 



rerouting network traffic operating in conjunction with a server cluster". 
Applicant has used the ordinary and customary meaning of the term "cluster 
server" as will be cleared to the one skilled in the art. The Examiner provided a 
far broader and expansive meaning of this term than the ordinary meaning, to the 
content distribution system or the network address translating environment to 
which the cited references relate. However , ^plicant clearly and distinctly 
differentiated between the examiner broad interpretation and a server cluster that 
provides high reliability, and offers r^undancy^ fault tolerance and scalability. 
Applicant made the distinction both in the specifications as filed, and in the 
amendment. Applicant respectfully reminds die OfBce that the applicant may act 
as his own lexicographer (MPEP2173.01), and that "Importantly, the person of 
ordinary skill in the art is deemed to read the claim term not only in the context of 
the partictdar claim in which the disputed term appears, but in the context of the 
entire patent, including the specification. " and "a patent applicant may 
consistently and clearly use a term in a manner either more or less expansive than 
its general usage in the relevant community, and thus expand or limit the scope of 
the term in the context of the patent** (Collegenet Inc. v. Applyyourself Inc., CAFC 
04-1 202,-1222,-125 1). Thus the Examiner should have given the term server 
cltister an interpretation consistent with both by using the ordinary and customary 
meaning of the term, and by specific definition, none of which is present in any 
form in the cited art 

4) AppUcantrequests AGAIN that the office will DISTINCTLY AND 
SPECIFICALLY point out \\iiere in the cited references the limitations of : 
returning the same packet to the client, and of operating within a server cluster 
exist in any of the cited references, or reconsider and vrithdraw the rejection, 

5) Applicant amended claim 1 to further show that the first server and the second 
server both belong to the same server cluster, and each has a unique internet 
address. The section the Office used to reject claim 1 relates to a DNS service. 
The operation of a server cluster distinctly differs fiom that of a DNS server. 
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Whereas the DNS server receives a query obtaimng a name, and returns an 
address equivalently representing the requested name. The DNS server does NOT 
reqiiire the return address to be in the same server as the DNS server, neither is 
such arrangement taught by McCanne* The server cluster of tibe present invention 
comprises at least two separate servers — the claimed first and second servers, that 
belong to a single entity, called a server cluster, which is defined to provide 
redundancy. In the present invention, as claimed in claim 1 , the first server 
indicates to the client that the service request originally directed to it should be 
directed to a second address within the server cluster. The redirection is not 
performed by intercepting the communication packets and redirecting them from 
the first server directly to a second server, but rather by instructing the client to 
redirect the request to the second server in the cluster, represented by the service 
address. Again such feature is not disclosed, suggested, or hinted in any of the 
cited references, which do not relate at all to a server cluster and which do not 
teach redirection to be carried out by the client. 

6) Furthermore, ^plicant amended the claim to add the limitation of obtaining not 
merely a redirection address from the redirection database, but also obtaining at 
least one redirection flag, which shall be used by the client to indicate if 
redirection should occiir, if the redirection is permanent or is it temporary, such as 
a one-time redirection, or that the client should redirect its service requ^ts only 
until a lease (e*g. a DHCP lease of the client) expires. While the Office has taken 
the position that Albert's dispatch flag is somehow equivalent to the redirection 
flag. The Albert dispatch flag is describe (CoL 16, 11. 27-3 1) as indicating 
^whether the packet is to be dispatched to the forward IP address included in the 
fixed affinity^ However Albert further clarifies that ''the difference between . 
dispatched and directed traffic is that dispatched traffic is forwarded directly 
from a forwarding agent to a specific server without translating the destination IF 
address of the packet. Instead, ct forwarding address contained in an affinity is 
used to forward the packet If the connection is not dispatched but directed by the 
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forwarding agent, then the packet IP destination must be translated using NAT if 
the packet is redirected to a specific server. " Clearly the forwarding agent, rathea- 
tban the client, performs the redirection, and therefore the dispatch flag directly 
teaches away firom the present invention and does not disclose the permanent 
redirection flag claimed. Moreover, Albert further presents that ''Not setting the 
dispatch flag indicates that the packet is to be forwarded based on the address 
provided in the packet IP header, "(col. 16, 11. 44-45), again clearly not indicating 
any tune limits of redirection. Furthermore The Office claimed that CoL 16, 11. 
42-46, Albert discloses a flag indicating whether the client is expected to perform 
the redirection permanently to the sendee address. LL. 42-46 read: ''If forward 
IP address 608 is zero, then the packet is dropped after processing statistics as 
indicated by an information flag 606. Not setting the dispatch flag indicates that 
the packet is to be forwarded based on the address provided in the packet IP 
header. " Clearly, Albert does not relate in any form to a redirection performed 
by the client, permanently or otherwise. Neither does, as the Office claims, 
Albert discloses a redirection flag indicating that the client should continue 
redirection until a lease is expired. Instead, in Albert's Col. 25, 1166-7 and coL 26 
11. 1-4^ Albert states:" A copy flag 1068 also uses the same bit code as the interest 
mask Each bit specifies whether a copy of the matching packet is to be forwarded 
to the server. If the bit is set for the packet type, the forwarding ageni sends a 
copy of the matching packet and refers to a hold flag 1069 to determine what to 
do with the original packet. Hold flag 1069 also itses the same bit code as the 
interest mask Hold flag 1069 determines whether the forwarding agent forwards 
the packet to the service manager or, if possible, holds the packet and waits for 
the service manager to send a fixed affinity that specifies how the packet should 
be forwarded by the forwarding agent. If the bit is not set for the packet type, then 
the forwarding agent forwards the packet. If the bit is set, then the forwarding 
agent holds the packet, if possible. If the packet cannot be held by the forwarding 
agent for some reason (e.g., lack of storage) then the forwarding agent forwards 
the packet to the Manager .^^ Nothing in the cited paragraph, nor elsewhere in 
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Albert, teaches that the client is to continue forwarding service requests to the 
second server until the expuBtion of any lease. 

7) As none of the possible claimed flags exists in neither McCanne nor Albert, 
applicant overcame the prior art rejections that were directed to claims 1 , 4, 5, 6, 
7, and 8, the limitations of which were combined into claim 1 and all its 
dependent claims. 

8) Applicant amended claim 1 5 to reflect that flags that the redirection happens 
between separate servers within the cluster, and that the redirection database 
contain flags similar to those of claim 1. By the same arguments provided for 
claim 1 above ^plicant submits that as neither McCanne nor Albert disclose any 
of the claimed flags the claim overcomes the prior art Additionally, the claim is 
directed to a server cluster and neither Albert nor McCanne disclose a server 
cluster as clearly defined by applicant in paragraph [02] and others of the 
specifications. Furthermore, neither Albert nor McCanne teach a cluster server at 
ail, nonetheless a cluster server architecture in which a receiver server indicates to 
the database that the server is able to handle specific client requests. As the 
Office failed to show the claimed limitations, the applicant overcame the cited 
prior art and the claims should be allowed. 

9) Applicant amended claim 20 to show the flags simUar to those claimed in claims 
1 and 15. As the arguments regarding the flags presented in the comments for 
claims 1 and 15 sinodlarly apply, and as none of the cited art discloses a client 
adapted to receive the original service request with the redirection header, 
applicant submits that the cited prior art has been ov^wme and that the claim is 
allowable, 

10) The dependent claims are allowable in light of their containment of all the 
limitations of the independent claims, which were shown allowable in view of all 
the cited prior art 
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1 i) Applicant has made a good fai^ effort to address each and every point made by the 
Examiner, and amended the claim in order to place the application in condition for 
allowance. Should the Examiner find any deficiency in this amendment or in the 



1 2) In ligjit of the showing and all other reasons stated above, applicant believes that the 
rejection jHesented by the Examiner in the office action mailed to applicant Jiuie 1 7, 2005 
were overcome and that the claims as amended are in condition for allowance. 
Reconsideration and withdrawal of the rejection and issue of a notice of allowance on all 
pending claims is solicited. 



Respectfully Submitted 



Shalom Wertsberger 
Reg. Num 45^59 
30 Fern Lane 
" South Portland^ ME 04106 
Phone: (207) 799-9733 
Fax: (207) 767-5324 

Agent for Applicant 
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application, or should the Examiner believe for any reason, that a conversation with 
applicant's agent may further the allowance and issuance of this application, the 
Examiner is kindly requested to contact Shalom Wertsberger at telephone (207) 799- 



9733. 
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